REMARKS 



In the Office Action of February 5, 2008, the Office set forth the following 
rejections: 

fa) Claims 1-14, 17-23, 26-28, 30-39 and 41-51 under 35 USC §1 02(b) as being 
anticipated by U.S. 6,389,467 to Eyal (referred to as the Eyal reference); and 

(b) Claims 15, 16, 24, 25, 29 and 40 under 35 USC §1 03(a) as being 
unpatentable over the Eyal reference in view of U.S. 2003/0236906 to Klemets et al. 
(referred to as the Klemets reference). 

Subject Matter of Instant Application: Object Selection/Creation 

The instant application describes a media source resolver interface for creating 
media source objects or byte stream objects. Media source objects are components 
capable of parsing and interpreting data "pointed to" by a URL or contained in a byte 
stream object. A byte stream object is an encapsulation representing a stream of data. 
A media source resolver interface can provide both synchronous and asynchronous 
methods of creating media source objects and byte stream objects without requiring 
prior knowledge about the format of data represented by the specified URL or byte 
stream object. 

Various examples are described with respect to interfaces (e.g., APIs), such as 
the following: 

(a) At 1f[0087], the instant application describes a so-calied 
"IMFSourceResolver" interface that exposes seven methods, including 
synchronous techniques "CreateObjectFromURL" and 
"CreateObjectFromByteStream" and asynchronous techniques 
"BeginCreateObjectFromURL" and "BeginCreateObjectFromByteStream". 

(b) At [0088] and [0089], the instant application also describes a so- 
called "IMFResolutionCallback" caller supplied resolution callback interface that 
exposes three methods, including "HandleResolution". 

(c) At % [0090], the instant application also describes a so-called 
"IMFSchemeHandler" interface that exposes three methods, including 
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"BeginCreateObject" for creating an object that can connect and read data from a 
resource pointed to by a specified URL. 

(d) At [0091], the instant application also describes a so-called 
"IMFByteStream Handler" interface that exposes five methods, including 
"BeginCreateObject" for creating a resolution object from a supplied byte stream. 

As explained in the instant application, such interfaces and associated methods 
can, for example, create a media source object or a byte stream object from a URL or 
create a media source object from a byte stream object. 

Claim 1 

To clarify further, consider claim 1, as currently amended: 

receiving a uniform resource locator (URL) as associated with one of a 
plurality of applications requesting media content; 

identifying a scheme associated with the URL; 

selecting a first object operable to handle the identified scheme associated 
with the URL to access parameter dafa from a location specified by a- uniform 
r e source locator (URL) based of a scheme of the URL; and 

based on the accessed parameter data, selecting a second object 
operable to read media content of a given type from the location specified by the 
URL bas ed o n dat a a cq u ired using tho first object . 

Hence, the method of claim 1 may be a method performed by an interface that 
services a plurality of applications that can request media content. Per the dependent 
claims, the first object and/or the second object are specified (e.g., to create a media 
source object or a byte stream object from a URL or create a media source object from 
a byte stream object). 

Claim 17 

To clarify further, consider claim 17, as currently amended: 
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receiving a uniform resource locator (URL) specifying a location of media 
content as associated with one of a plurality of applications reguesting media 
content; 

determining a scheme of [[a]] the uniform rosourc o locator (URL) URL 
sp e cifying a location of - m e di a c ontent; 

using the scheme to produce a byte stream object that to handle the 
determined scheme associated with the URL to access parameter data; 

using the byte stream object to generate[[s]] a byte stream from the media 
content; and 

using at least a portion of the byte stream to produce a source object that L 
based on the accessed parameter data, reads acc e sses the media content of a 
given type, from the location specified by the URL , 

Hence, the CRM claim 17 may be to implement an interface that services a 
plurality of applications that can request media content. In claim 1 7, a "byte stream 
object" and a "source object" are explicitly recited and follow from receipt of a URL (i.e., 
URL to byte stream object to source object). 

Eyal Reference: Media Search and "Data Type" Stored in Database w/Link 

The title of the Eyal reference is "Streaming Media Search and Continuous 
Playback System of Media Resources Located by Multiple Network Addresses". It is a 
47 page document that is directed to a network enabled device that receives search 
criteria and accesses a memory that includes a plurality of network addresses where a 
media playback component of the device plays back media resources provided by at 
least some of the addresses (i.e., according to the search). 

As shown explicitly in Fig. 1 of the Eyal reference, a playback interface is 
provided (block 160). Fig. 13 of the Eyal reference shows how a user, when presented 
media via a user interface (block 1110), can play back media clips (block 1 1 40). As a 
system, Fig. 19 of the Eyal reference shows how a network server module 1770 allows 
a playback component 1710 to access media via URL links. 
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Given this evidence, it is clear that the playback interface module 160 of Fig. 1 is 
for a user to define and execute search criteria for media playback (col. 1 3, lines 37-39). 
For further support, at col. 18, lines 9-11, appears a heading "Media Search Engine" 
followed by "Embodiments of the invention locate web resources on a network such as 
the Internet". Once a resource is located, the Eyal reference uses a verification process 
that relies on use of a media player: "The response provided by the media player to the 
link determines whether the links are verified". 

Yet further, the Eyal reference states that "embodiments enable network links to 

files of a particular data type to be rapidly accumulated and stored in a database" (col. 

19, lines 11-13) where the database is used to store "information that characterizes the 

files associated with the links" (col. 19, lines 18-21). With respect to data types and 

associated protocols, at col. 21, lines 35-46, the Eyal reference states: 

Each URL signaled from web server module 270 has a network protocol. 
For media resources, and specifically audio files, types of protocols include 
"HTTP" protocol, "PIMM" protocol (RealNetworks, having RM extensions), or 
"RTSP" protocol (having RAM extensions). The URLs signaled by web 
server module 270 include the protocol at an initial portion of the string 
forming the URL. Preferably, for HTTP protocol files, the string portion 
corresponding to HTTP is replaced with "PIMM". This adjustment prevents 
playback component 21 1 from failing as a result of a bug in the media 
playback component, particularly if the playback component 211 is a 
RealNetworks Player™. 

With respect to data types and media players, at col. 27, lines 14-19, the Eyal reference 



In an embodiment, the flow process employs a streaming media player 
component installed on the user terminal. The media player may be 
preexisting on the user terminal. Examples of media players for use with an 
embodiment include RealNetwork Player™, Microsoft Windows Media 
Player™, and Apple QuickTime™. The application described in the process 
may be web based or installed the user terminal. 
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Based on this evidence, it appears that the system of the Eyal reference relies merely 
on storage of data type with a link in a database and, for protocols, on replacing a string 
portion as to protocol type (e.g., "PNM"). 

Evidence relied on by the Office (in order cited): 
Eyal Reference: 



E1. 


Column 


2, lines 5-26 


E2. 


Column 


3, lines 45-65 


E3. 


Column 


12, lines 1-10 


E4. 


Column 


2, lines 30-45 


E5. 


Column 


12, lines 13-35 


E6. 


Column 


2, lines 35-45 


E7. 


Column 


3, lines 50-60 


E8. 


Column 


12, lines 35-65 


E9. 


Column 


2, lines 5-43 



Klemets Reference: 

E10. Para [0099] 
E11. Para [0095] 

Rejection of Claims 1-14. 17-23, 26-28. 30-39 and 41-51 under 35 USC $1 02(e) 
The Office rejected claims 1-14, 17-23, 26-28, 30-39 and 41-51 as being 
anticipated by various portions of the Eyal reference. 

Findings of Fact by the Office: 

FF1 . The Eyal reference discloses a method comprising selecting a first object 
operable to access data from a location specified by a uniform resource locator (URL) 
based on a scheme of the URL (OA 2/05/08 at pp. 2 and 3, citing E1-E3). 
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FF2. The Eyai reference discloses a method comprising selecting a second 
object operable to read media content of a given type from the location specified by the 
URL based on data acquired using the first object (OA 2/05/08 at pp. 2 and 3, citing E1 ). 

FF3. The Eyal reference discloses wherein the selection of the second object is 
additionally based on information contained in the URL indicating a type of the 
multimedia data (OA 2/05/08 at p. 3, citing E4, E5). 

FF4. The Eyal reference discloses wherein the second object is a source object 
(OA 2/05/08 at p. 4, citing E1). 

FF5. The Eyal reference discloses wherein the second object is produced using 
a byte stream handler selected from a list of byte stream handlers and wherein each 
byte stream handler in the list has a selection value associated therewith (OA 2/05/08 at 
p. 6, citing E8). 

FF6. The Eyal reference discloses a computer-readable medium including 
computer-executable instructions for performing operations comprising: determining a 
scheme of a uniform resource locator (URL) specifying a location of media content, 
using the scheme to produce a byte stream object that generates a byte stream from 
the media content; and using at least a portion of the byte stream to produce a source 
object that accesses the media content (OA 2/05/08 at pp. 6-7, citing E1-E3, E9). 

FF7. The Eyal reference discloses wherein the operation of producing a byte 
stream object includes choosing a scheme handler and using the chosen scheme 
handler to produce the byte stream object (OA 2/05/08 at p. 7, citing E1, E6, E7). 
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Rejection of Claims 15, 16, 24, 25, 29 and 40 under 35 USC §1 03(a) 

The Office rejected claims 15, 16, 24, 25, 29 and 40 as being unpatentable over 
various portions of the Klemets reference. The Office set forth these reasons in 
Findings of Fact 8-13, below. 

FF8. The Klemets reference discloses wherein the second object is produced 
using a byte stream handler selected from a list of byte stream handlers and wherein 
each byte stream handler in the list has a cost value associated therewith (OA 2/05/08 
at p. 21, citing E10, E11). 

FF9. The Klemets reference discloses wherein the second object is produced 
using a byte stream handler selected from a list of byte stream handlers and wherein 
each byte stream handler in the list has a cost value associated therewith, the cost 
value indicating how many bytes must be read by the byte stream handler in 
determining if the byte stream handler is appropriate for selecting the second object (OA 
2/05/08 at pp. 21 and 22, citing E10, E11). 

FF10. The Klemets reference discloses wherein the operation of producing a 
source object includes choosing a byte stream handler from a list of byte stream 
handlers and using the chosen byte stream handler to produce the source object and 
wherein the list of byte stream handlers is ordered based on a cost values associated 
with the byte stream handlers (OA 2/05/08 at pp. 22 and 23, citing E10, E1 1). 

FF1 1 . The Klemets reference discloses wherein the operation of producing a 
source object includes choosing a byte stream handler from a list of byte stream 
handlers and using the chosen byte stream handler to produce the source object and 
wherein and each byte stream handler in the list has a cost value associated therewith, 
the cost value indicating an amount of data that must be read by the byte stream 
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handler in determining if the byte stream handler is appropriate for producing the source 
object (OA 2/05/08 at p. 23, citing E10, E1 1). 

FF12. The Klemets reference discloses wherein the operation of producing a 
source object includes using a look-up process to: select a number of byte stream 
handlers; and invoke the byte stream handlers one at a time in a predetermined order 
based on cost values associated with the selected byte stream handlers until a byte 
stream handler produces a source object (OA 2/05/08 at p. 24, citing E10, E1 1). 

FF13. The Klemets reference discloses wherein the byte stream object is 
produced using a scheme handler that is selected from a list of scheme handlers, the 
list being selected based on the scheme of the URL and ordered based on cost values 
associated with each of the scheme handlers in the list (OA 2/05/08 at pp. 24 and 25, 
citing E10, E11). 

Principles of Law: 

Per M PEP §2131 : A claim is anticipated only if each and every element as set 
forth in the claim is found, either expressly or inherently described, in a single prior art 
reference. 

Per MPEP §2143 : 

The rationale to support a conclusion that the claim would have been 
obvious is that: 

(i) all the claimed elements were known in the prior art ; 

(ii) one skilled in the art could have combined the elements as 
claimed by known methods, with no change in their respective functions : 
and 

(iii) the combination yielded nothing more than predictable results to 
one of ordinary skill in the art. 
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It can be important to identify a reason that would have prompted a person 
of ordinary skill in the relevant field to combine the elements in the way the 
claimed new invention does. 

The rationale to support a conclusion that the claim would have been 
obvious is that a person of ordinary skill in the art would have been 
motivated to combine the prior art to achieve the claimed invention and that 
there would have been a reasonable expectation of success . 

If any of these findings cannot be made, then this rationale cannot be used 
to support a conclusion that the claim would have been obvious to one of 
ordinary skill in the art. 

PerMPEP §2143.01: 

If the proposed modification or combination of the prior art would change 
the principle of operation of the prior art invention being modified, then the 
teachings of the references are not sufficient to render the claims prima 
facie obvious. 

Applicant's Position 

Applicant submits that various Findings of Fact (FF) of the Office that rely on 
evidence in the Eyal reference are in error. For example, FF2 is unsupported by 
objective evidence of record. To demonstrate why, respectfully directs the Office to the 
already presented summary of the subject matter of the instant application and the Eyal 
reference. Based on this evidence, it appears that the media search system of the Eyal 
reference relies merely on database storage of a media data type with a link to the 
media and, for protocols, it relies on replacing a string portion as to protocol type (e.g., 
"PNM"). After a detailed review of the Eyai reference, Applicant finds no evidence to 
support FF2, which contends that the Eyal reference discloses "selecting a second 
object operable to read media content of a given type from the location specified by the 
URL based on data acquired using the first object". 

As another example, consider FF3, which contends that the Eyal reference 
discloses "determining a scheme of a uniform resource locator (URL) specifying a 
location of media content, using the scheme to produce a byte stream object that 
generates a byte stream from the media content; and using at least a portion of the byte 
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stream to produce a source object that accesses the media content". Applicant submits 
that the system of the Eyal reference relies on relatively simply database entries that 
associate a link to media with a data type for that media. Applicant fails to find evidence 
of a byte stream object or a source object and, hence, fails to find evidence of producing 
a byte stream object and producing a source object. 

Further, Applicant submits that any modification of the system of the Eyal 
reference to meet the claimed subject matter would change the principle of operation of 
the Eyal reference. In principle, operation of the system of the Eyal reference relies on 
(i) a search engine and (ii) a database that stores links to media with associated data 
types of the media. Applicant submits that any modification of the system of the Eyal 
reference for object creation (for byte stream or source objects) would be superfluous 
as the Eyal reference already ensures media compatibility with a media player via a 
verification process and as it stores, in a database, data type for media in association 
with a link to the media. The search engine of the Eyal reference relies on the 
information stored in the database - where data type is known and compatibility 
verified. 

As explained, the subject matter of claim 1 is directed to receiving a uniform 
resource locator (URL) as associated with one of a plurality of applications requesting 
media content, identifying a scheme associated with the URL, selecting a first object to 
handle the scheme associated with the URL to access parameter data and based on 
the accessed parameter data, selecting a second object operable to read media content 
of a given type. Independent claims 17, 35 and 43 recite related subject matter. 
Applicant submits that the Eyal reference does not disclose, teach or suggest the 
subject matter of independent claims 1 , 17, 35 and 43. 

Response to Specific Evidence: E2 and E3 

The Office cites E2 as disclosing the first object of claim 1 in FF1 . The cited 
portion (E2) of Eyal, accentuates the order in which media resources are presented. 
For example, the cited portion describes Eyal's database signaling the plurality of links 
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to the web server module in the designated order . (Eyal Column 3, lines 58-60). 
Further, the web server module of Eyal is described as signaling the plurality of links to 
the user terminal in the designated order . (Eyai Column 3, lines 54-55). The ordered 
signaling causes Eyal's terminal to load the media web resource located by each of the 
plurality of links into the media playback component in the designated order . (Eyal 
Column 3, lines 54-57). Eyal also teaches accepting user input via the user interface for 
directing the web server to alter the designated order in which the database signals the 
plurality of links to the web server module. (Eyal Column 3, lines 57-65). 

The word designated order is mentioned three times in the cited portion (E2) of 
Eyal alone. This evidence supports a finding of fact that, unlike claim 1, the Eyal 
reference emphasizes the "signaling of the plurality of links in the designated order." 
Claim 1 recites selecting a first object operable to handle the identified scheme 
associated with the URL. The aforementioned portion of Eyal however, fails to mention 
anything about identifying the scheme of the received URL or the network enabled 
device's ability to handle the identified scheme. Accordingly, E2 fails to teach the first 
object selection of claim 1 . 

Further, E3 is also cited as disclosing the first object of claim 1 in FF1 . The cited 
portion of Eyal (E3) describes the system building a database of addresses including 
URLs for network and Internet sites. (Eyal Column 12, lines 4-6). Media web sites in 
Eyal may allow users to access media, to locate media on other types of network, or to 
locate media sites via a search engine. (Eyal Column 12, lines 6-10). The cited portion 
(E3) of Eyal describes the network enabled device accessing the media resource . 
However, the cited portion of Eyal (E3) does not teach the network enabled device 
accessing parameter data or selecting the first object operable to handle the identified 
scheme associated with the URL as recited in claim 1. Therefore, Applicants 
respectfully submit that Eyal's network enabled device is not analogous to the first 
object as recited in claim 1 . 
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Conclusion : The evidence cited by the Office (E2 and E3) does not support its 
finding of fact (FF1). Consequently, the Office's legal conclusion as to claim 1 is in 
error. 

Response to Specific Evidence: E9 

In FF6, the Office cites E1-E3 and E9 as disclosing the computer readable 
medium of claim 1 7. Claim 1 7 recites, in part, determining a scheme of the URL 
received from one of a plurality of applications. The Office equates determining a 
scheme of the URL element of claim 17 with Eyal's network enabled device accessing 
media resource at the address (Office Action at p. 6). 

The Office also asserts that Eyal's network server module signaling the address 
to the network enabled device to cause the device to access the media network 
resource, and to signal media playback component to load the media network resource 
is analogous to following three elements of claim 1 7: 

(1 ) using the scheme to produce a byte stream object to handle the determined 
scheme associated with the URL to access parameter data; 

(2) using the byte stream object to generate a byte stream from the media 
content; and 

(3) using at least a portion of the byte stream to produce a source object that, 
based on the accessed parameter data, reads the media content of a given type, from 
the location specified by the URL. 

The cited evidence E9 does not support such a finding (FF6) mainly because 
Eyal's search criterion is not analogous to the URL scheme determination element of 
claim 1 7. Eyal's network server module uses the search criteria to search the database 
to locate an address. In contrast, claim 17 recites using the URL scheme to produce a 
byte stream object . Eyal does not produce anything from the search criteria. Eyal 
merely selects an address from the database which is associated with a class of 
information that matches with the search criteria. 
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Because Eyal does not teach producing the byte stream object of claim 17, Eyal 
also does not teach producing the source object of claim 1 7. Unlike Eyal's search 
criteria or selected database address, the source object of claim 17 is produced using 
the byte stream object and for reading the media content. 

Conciusion : The evidence cited by the Office (E1-E3 and E9) does not support its 
finding of fact (FF6). Consequently, the Office's legal conclusion as to claim 17 is in 
error. 

Obviousness Rejections: Eyal in view of Klemets 

The Office Action rejected claims 15, 16, 24, 25, 29 and 40 under 35 U.S.C. 

103(a) as being unpatentable over the Eyal reference in view of U.S. 2003/0236906 to 

Klemets (Office Action at p. 21 ). Applicant respectfully directs the Office to the 

foregoing evidence and arguments. In particular, Applicant directs the Office to the 

evidence as to the principle of operation of the system of the Eyal reference, noting that 

perMPEP §2143.01: 

If the proposed modification or combination of the prior art would change 
the principle of operation of the prior art invention being modified, then the 
teachings of the references are not sufficient to render the claims prima 
facie obvious. 

For this reason alone, Applicant submits that the Eyal reference cannot serve as 
a primary reference in support of a prime facie case of obviousness. Hence, Applicant 
submits that the pending claims are patentable over the Eyal reference in view of the 
Klemets reference. 

Claim 15 

As to claim 15, the Office Action asserts that the Eyal reference does not teach 
elements of claim 15, but that the Klemets reference teaches the elements of claim 15 
(Office Action at p. 21 ). These rejections rely on Findings of Fact 8 through 13 (FF8- 
1 3), as presented above. 
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In support of FF8-FF13, the Office Action cites E10 and E1 1 (Office Action at p. 
21 ). The evidence E1 1 describes a process for determining whether to cache 
streaming media content on a client device. This portion of the Klemets reference fails 
to provide evidence sufficient to teach or suggest producing the second object using a 
byte stream handler selected from a list of byte stream handler having a cost value 
associated therewith as recited in claim 15. The evidence E10 describes details 
regarding the link bandwidth values and actions associated with various ranges of the 
link bandwidth values. 

As discussed above, the Eyal reference fails to disclose the first object and the 
second object of claim 1 . The cited portion of the Klemets reference does not cure the 
infirmity of the Eyal reference. Accordingly, the combination of the Eya! and Klemets 
references does not teach or suggest the subject matter of claim 1 5. 

Conclusion 

Applicant submits that, for at least the reasons above, claims 1-14, 17-23, 26-28, 
30-39 and 41 -51 are not anticipated under 35 USC §1 02(b) by U.S. 6,389,467 to Eyal 
(referred to as the Eyal reference) and that claims 15, 16, 24, 25, 29 and 40 are not 
unpatentable under 35 USC §1 03(a) over the Eyal reference in view of U.S. 
2003/0236906 to Klemets et al. (referred to as the Klemets reference). 

Applicants therefore respectfully request the Examiner's reconsideration and 
withdrawal of the rejections as to claims 1-51 and an indication of the allowability of 
same. 

In view of the amendments and remarks set forth herein, the application is 
believed to be in condition for allowance and a notice to that effect is solicited. 
Nonetheless, should any issues remain that might be subject to resolution through a 
telephonic interview, the Examiner is invited to telephone the undersigned attorney. 
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Respectfully submitted, 




Brian Pangrle Date 
Lee & Hayes, PLLC 
Reg. No. 42,973 
Telephone: (509)-324-9256 
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